AWS環境上のIPv4アドレス数を減らしたいときに確認するチェックリスト

荒平祐次(arap)

2023.09.23

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、AWS事業本部の荒平(@0Air)です。

最近、「IPv4アドレス数を減らしたいが、どうするべきか分からない」「確認方法が分からない」「手が付けられない」というお話を耳にすることがあります。

恐らく、以下の記事が起因になっていると思われます。(表の抜粋)

パブリック IP アドレスのタイプ	現在の料金/時間 (USD)	新料金/時間 (USD) (2024年2月1日より適用)
VPC 内のリソース、Amazon Global Accelerator、AWS Site-to-Site VPN トンネルに割り当てられた、使用中のパブリック IPv4 アドレス（AWSが提供するパブリック IPv4 アドレスおよび Elastic IP アドレスを含む）	無料	$0.005
起動中の EC2 インスタンスに割り当てられた追加（セカンダリ）のElastic IP アドレス	$0.005	$0.005
アカウント内の未割り当ての Elastic IP アドレス	$0.005	$0.005

これまでは、使用中のパブリックIPv4アドレスに対して課金は発生しませんでしたが、2024年2月1日より課金が適用されるようになります。
なお、BYOIPにより環境へ持ち込んだIPアドレスは対象外です。

1ヶ月を730時間とすると、1 IPv4アドレスあたり 3.65ドルが課金されます。
塵も積もれば山となるということで、数十〜数百IPアドレスなど多く利用されるほどインパクトが大きくなります。

IPv4アドレス数が減らせるかどうかは、各環境上において全く異なるため、チェックすれば確実にIPv4アドレス数を減せるものではないですが、ひとつの参考にしていただければと存じます。

0. 前提

前述の通り、環境によって適用できる・できないがあるため、全てベストプラクティスに沿っている場合などは全く減らない可能性があります
IPv4アドレス数の低減策を全て網羅しているものではありません
パフォーマンスに影響が及ぶ変更を行うときは、慎重な事前調査が必要です

1. 現状把握

まずは、環境上で利用しているIPv4アドレス数がどのくらい存在しているかを確認されることをオススメします。

DevelopersIOでは、既にIPv4アドレスの利用時間、環境のチェック方法が紹介されているので、こちらをご参照ください。

Amazon VPC IP Address Manager (IPAM)を用いたPublic IPアドレスの使用状況抽出はこちら

Organizations環境にて確認したい場合はこちら

2. 対策

IPv4アドレス数を低減、集約できる可能性がないか考えていきます。
主観で「すぐに検討したい度」を設定しましたので、順に紹介します。チェック欄はご自由にお使いください。

チェック	すぐに検討したい度	項目
	★★★	i. アタッチされていない不要なElastic IPアドレスが無いか確認する
	★★★	ii. サブネットのIPv4アドレス自動割当をオフにする
	★★	iii. Elastic Load Balancing (ELB)サービスの不要なAZを削除する
	★★	iv. オートスケール構成のEC2インスタンスサイズの見直し
	★	v. 利用しているロードバランサーの集約
	★	vi. NAT Gatewayの集約
	☆	vii. Global Acceleratorの利用

i. アタッチされていない不要なElastic IPアドレスが無いか確認する

これは今回の料金体系が適用される前にも有効な対策です。（現時点でも課金対象のため）

「1.現状把握」章でも紹介しておりますが、まずはアタッチされていない不要なIPv4アドレスが無いか、Amazon VPC IP Address Manager (IPAM)から確認します。

関連付けれていないEIPが想定より多い場合は削除を検討します。

「不要な」と記載した通り、将来的に利用を想定しているEIPは誤って消さないように注意しましょう。

また、ただ単純にEC2へのSSH/RDPのためにIPv4アドレスを利用している場合は、Systems Manager Fleet Managerや、EC2 Instance Connect Endpointを代替利用できる可能性があります。
アタッチされているIPv4アドレスに対しても、一度棚卸しをしたほうが良いでしょう。

ii. サブネットのIPv4アドレス自動割当をオフにする

サブネットレベルでIPアドレスの自動割当てを有効にしている場合は、このサブネットに作成されるRDSやECSなど本来IPv4アドレスが不要なリソースにも割り当てされてしまい、課金対象となります。

EC2のみ利用している場合も、起動設定で解消できるケースがありますので、もし有効化されている場合は見直しましょう。

補足：IPv4自動割当をオフにしたのみでは、IPv4アドレス数は削減できません。EC2の再作成が必要となります。自動割当をオフにした新規サブネットを用意し、そちらに移行を検討・検証しましょう。

パブリックIPv4アドレスの自動割当を無効にして複製するには、IaC(Terraform)を利用すると良いでしょう。
Zennにてその手法を執筆されている方が居ましたので、紹介いたします。

iii. Elastic Load Balancing (ELB)サービスの不要なAZを削除する

Application Load Balancer (ALB)およびNetwork Load Balancer (NLB)を利用する際、盲目的に3AZでデプロイしているケースがあると思います。

過去に起きた東京リージョンの障害では、「ALBが2AZ設定では切り離せなかった」と評する記事も出ていたので、これをご存知の方は積極的に3AZにするシーンがあったかもしれません。
（参考：AWS障害、“マルチAZ”なら大丈夫だったのか？　インフラエンジニアたちはどう捉えたか、生の声で分かった「実情」 - ITmedia）
※ 但し、この件は様々な議論があるところであり、ここでは言及しません

システム全体のSLA次第ではありますが、3AZ利用が必須でない場合は、不要なAZを削除することもひとつの手です。

補足：3AZ→2AZ化は、開発環境や安定したワークロード環境への適用が向いており、スパイクでトラフィックが増大するような環境では、2AZ化により性能に悪影響を及ぼす可能性があります。

iv. オートスケール構成のEC2インスタンスサイズの見直し

Auto ScalingにてIPv4アドレスを付与して運用している環境では、EC2のインスタンスサイズ見直しによりIPv4アドレス数を減らせる可能性があります。

例えば、m6i.large インスタンスを10台利用している場合、m6i.xlarge × 5台に集約し、アプリケーションを最適化します。
なお、この場合はAZの配置状況など、必要な可用性レベルを満たせるように十分な検討が必要です。

v. 利用しているロードバランサーの集約

ALB, NLBなど、ロードバランサーは複数のサービスで共用できる可能性があります。

Qiitaにて、具体的にECSの複数サービスを1つのALBへ集約する手法が執筆されておりましたので、こちらで紹介させていただきます。

ALB/NLBのService Quota内であれば、ALBの機能にてまとめることでIPv4アドレス数を節約することが可能です。
ただし、過度な集約はSPOFを招く可能性があり、適用する前に十分検討されることを勧めます。

vi. NAT Gatewayの集約

NAT Gatewayが複数個同一環境にデプロイされている場合は、集約できる可能性があります。

これは大きめの環境に限った話になってしまいますが、Transit Gatewayを既に利用している環境では、アウトバウンド通信を集約することでNAT Gatewayを減らし、IPv4アドレス使用数を削減できます。

vii. Global Acceleratorの利用

適用できる構成が少し限定されますが、Global Acceleratorを利用すればIPv4アドレス数を減らせる可能性があります。

以下のAWS公式ブログでは、「AWS Global AcceleratorをVPC 内のプライベートリソースと使用する」方法について言及されています。

(引用：上記ブログより)

但しこの構成は、Global Acceleratorの料金を加味するとかえって高くなる可能性があるため注意が必要です。

3. これからどうしていくべきか

正直、既存の環境に変更を加えるのは難しいという環境も数多くあると思います。
ですが、IPv4アドレスは有限であり、今後値上げが無いとも断言できない（AWSに限らず、他パブリッククラウドも）ので、これから新規で立ち上げるシステムには少し考慮を進めていくべきと考えます。

既にあるVPCにて、新規システムを開始する際には、以下を頭の片隅に入れておくといつか役に立つ可能性があります。

既存のVPCには、デフォルト(IPv4)に追加でIPv6 CIDRを関連付ける
IPv4, IPv6のDualStackサブネットを新規に作成する
IPv4アドレスの自動付与を無効化 (必要に応じてIPv4アドレスを手動付与)
IPv4通信はNAT Gateway、IPv6通信はEgress-Only Internet Gatewayを利用
これから開始するEC2などはDualStackサブネットにて作成し、IPv6対応のエンドポイントがあればそれを利用

現状では、IPv6に対応していないサービス(ex. Systems Manager)が存在するため、全てIPv6化することは難しいものの、将来を見据えてDualStack構成の検討を始めておくと良いと思われます。

デュアルスタック IPv6 アーキテクチャに関しては、以下のブログで詳しく解説がありましたのでご参照ください。

おわりに

「IPv6化対応、進めないといけないな」と思いながら数年経ってしまいましたが、ついに今回のアナウンスで本腰を入れて考えないといけなくなりました。
きっと私のような人も多いハズ・・・と思い筆を執りました。
なお、重ねてになりますが、全ての対策について言及できている訳ではありません。いい手法があれば別途コメントいただければと存じます。

本件は、コンサルティング部のSlackにてIPv6対応を相談したことが事の発端でした。
ご相談に乗っていただいた阿部洸樹さん、鈴木亮さん、しばたさん、本当にありがとうございました！！

このエントリが誰かの助けになれば幸いです。
 それでは、AWS事業本部コンサルティング部の荒平(@0Air)がお送りしました！